The term Programmable Logic Device (PLD) designates a class of devices that are programmable by end users to realize user-specific circuits. Examples of PLDs are FPGAs (Field Programmable Gate Arrays) and EPLDs (Erasable Programmable Logic Devices). To use a PLD, a user captures a circuit design using any of several capture/design tools. The user then uses the capture/design tool to convert the captured design into device-specific configuration data. The configuration data is commonly stored in an external storage device, such as an EPROM. Upon startup, the storage device supplies the configuration data to the PLD, thereby configuring the PLD to realize the user-specific circuit. Since the configuration data is often supplied in serial fashion, the configuration data is called a “bitstream”. The PLD, having read in the configuration data bitstream, is then configured to realize the user-specific circuit.
FIG. 1 (Prior Art) illustrates the loading of such a configuration data bitstream 1 from an external storage device 2 into a PLD 3 to realize a user-specific circuit. PLD 3 in this case is an FPGA (for example, a XC4000 series FPGA available from Xilinx, Inc. of San Jose, Calif.). PLD 3 includes a plurality of configurable logic blocks (called CLBS) 4, and a programmable interconnect structure 5, surrounded by a ring of configurable input/output blocks (called IOBs) 6. Each of the CLBs, the programmable interconnect structure, and the IOBS includes configuration memory cells, the contents of which determine how the CLBs, the programmable interconnect structure, and the IOBs are configured. Particular bits in bitstream 1 correspond to the contents of particular configuration memory cells. If, for example, two pieces of interconnect in the programmable interconnect structure controlled by a particular memory cell are to be connected in the user-specific circuit, then the particular bit in the bitstream corresponding to the memory cell for the particular programmable connection is set accordingly. Upon power-up of the FPGA, the bitstream 1 is transferred from external storage device 2 into PLD 3 to configure PLD 3 to be the user-specific circuit. In some prior art FPGA architectures, the protocol of the configuration data bitstream (including knowledge of which bits correspond to which configuration memory cells) is proprietary to the FPGA manufacturer, thereby providing individual users a level of security for their designs. Without knowledge of the protocol and the significance of the individual bits of the bitstream, another user cannot readily regenerate the actual circuit by inspection of the bitstream.
Over recent years, such user-specific circuits have typically increased in size and complexity. Simultaneously, market forces have reduced the amount of time practically available for developing such large user-specific circuits. In this environment, users have increasingly found it cost-effective to purchase from IP vendors (intellectual property vendors) pre-designed building blocks for use in the users' designs. Such a building block, sometimes called an “IP module” (intellectual property module), may have taken the IP vendor several engineer-years to design. An example of such an IP module is a PCI bus interface module. Rather than taking the time to design a circuit to perform the PCI interface function carried out by the IP module, the user 7 purchases the IP module 8 (in digital form) from the IP vendor. User 7 loads the IP module 8 into a capture/design tool 9 used to capture the user-specific design. User 7 then adds other user-specific circuitry 10 around the IP module using the capture/design tool 9, thereby designing the overall user-specific circuit. Once the overall user-specific circuit is designed, simulated, placed and routed, (steps in converting the user's design to device-specific configuration data) the capture/design tool 9 outputs the bitstream 1 for the overall user-specific circuit. As illustrated in FIG. 1, this bitstream 1 is then loaded into the external storage device 2 (for example, a PROM) so that the external storage device 2 will be able to supply the bitstream 1 to the FPGA on power-up.
A problem, however, exists in that the user's user-specific design can be copied. An unscrupulous second user could obtain a product of a first user on the market and copy the bitstream 1 that passes from the external storage device 2 to FPGA 3 on power-up. The second user could then use the copied bitstream to configure another FPGA (the same type of FPGA used by the first user), thereby replicating the first user's user-specific design and product. Protection against this copying of one user's design by another user is desired.
Erickson in U.S. Pat. No. 5,970,142 discloses one method wherein the bitstream transferred from the external storage device is in encrypted form and the PLD being configured has a key to decrypt the encrypted bitstream. The PLD receives the encrypted bitstream and uses its key to generate the unencrypted bitstream which is then loaded into the configuration memory cells to configure the PLD. Because in this method the key is not passed from the external storage device to the PLD, a copier would not have access to the key. Without the key, the copier would have a difficult time recovering the bitstream. Other methods are also known.
Not only is one user's copying of another user's design a problem, but the unauthorized reincorporation of a vendor-supplied IP module into other user designs is also a problem. Redman et al. in U.S. Pat. No. 5,978,476, as the present inventors understand it, discloses a design processing system that attempts to verify the identity of the user before allowing the user to use a vendor-supplied IP module. The design processing system that generates a programming file of bitstream information contains the IP module in an encrypted form as well as a permission verification system. The vendor to the IP module supplies an authorization code to a particular user where the authorization code is specific to the computer of the user (or is specific to a “dongle” supplied to the user). When an attempt is later made to use an IP module in the design processing system, the permission verification system requires the user to supply the authorization code. The permission verification system reads the computer's identification number (or the “dongle” number of a dongle attached to the computer) and checks this number with the supplied authorization code. If the number read from the computer is not appropriate for the authorization number provided by the user, then the user-verification process fails and the permission verification system does not allow the IP module to be decrypted. Aspects of the IP module are not revealed to the user. Moreover, the design processing system will not include configuration data for the IP module in the output programming file.
If, on the other hand, the number read from the computer is appropriate for the authorization code provided by the user, then the permission verification system allows the encrypted IP module to be decrypted and used by the design processing system. The user uses the design processing system to incorporate the IP module into the user-specific circuit designed by the user. When design of the user-specific circuit is completed, the design processing system outputs configuration data for the user-specific circuit in a programming file. The programming file of configuration data is then usable to program a PLD to realize the user-specific circuit. In this scheme, however, the configuration data so generated is output from the design processing system in unencrypted form. An authorized but nonetheless unscrupulous user could copy the programming file of bitstream information or a portion thereof and reuse it in an unauthorized fashion outside the control of the design processing system.
An improved system and method for protecting PLD designs is desired wherein a user is prevented from using an IP module in an unauthorized manner, and wherein one user is prevented from copying the user-specific circuit of another user.